Skip to content

fix: set authMethod to OIDC for SCIM-provisioned users#59

Merged
TerrifiedBug merged 1 commit intomainfrom
fix/scim-user-auth-method
Mar 7, 2026
Merged

fix: set authMethod to OIDC for SCIM-provisioned users#59
TerrifiedBug merged 1 commit intomainfrom
fix/scim-user-auth-method

Conversation

@TerrifiedBug
Copy link
Copy Markdown
Owner

Summary

  • SCIM-provisioned users were created with authMethod defaulting to LOCAL (schema default), which blocked OIDC login with "local account exists" error
  • Sets authMethod: "OIDC" in scimCreateUser so SCIM-provisioned users can authenticate via SSO
  • This also unblocks OIDC group sync — team assignment happens on first OIDC login via the groups claim, which requires successful sign-in

Test plan

  • Delete an SSO user from the database
  • Trigger SCIM sync from IdP
  • Verify user is recreated with authMethod: OIDC
  • Verify OIDC login succeeds (no "local account" error)
  • Verify team membership is assigned on login via OIDC group mappings

SCIM-provisioned users were created with authMethod defaulting to LOCAL,
which blocked OIDC login ("local account exists" error). Since SCIM
users authenticate via SSO, they must be created as OIDC users.

This also unblocks OIDC group sync — team assignment happens on first
OIDC login via the groups claim, which requires successful sign-in.
@github-actions github-actions bot added the fix label Mar 7, 2026
@greptile-apps
Copy link
Copy Markdown
Contributor

greptile-apps bot commented Mar 7, 2026

Greptile Summary

This PR fixes a correctness bug where SCIM-provisioned users were created with authMethod: "LOCAL" (the Prisma schema default), causing their subsequent OIDC login attempts to be rejected with a "local account exists" error. The one-line fix adds authMethod: "OIDC" to the prisma.user.create call in scimCreateUser, aligning SCIM provisioning with the intended SSO-only authentication model and unblocking OIDC group sync on first login.

Key observations:

  • The core fix is correct and minimal — newly SCIM-provisioned users will now have authMethod: "OIDC" and can authenticate via SSO immediately.
  • Adoption path gap: The adoption update (lines 120–126), which handles users that already exist when a SCIM create arrives, only updates scimExternalId and does not update authMethod. This means users who were SCIM-provisioned before this fix (with authMethod: "LOCAL" from the old default) remain blocked even after an IdP re-sync triggers the adoption branch. The OIDC login blocking logic in auth.ts (lines 229–241) explicitly rejects OIDC sign-in for authMethod: "LOCAL" accounts, confirming that this scenario is a real blocker. Adding authMethod: "OIDC" to the adoption update would self-heal those accounts without a separate data migration.
  • No security regression is introduced: the OIDC-vs-LOCAL blocking logic in auth.ts is unchanged, and the randomly generated temp password for SCIM users remains inaccessible for local login.

Confidence Score: 3/5

  • Safe to merge for new provisioning, but existing SCIM users with authMethod: "LOCAL" remain broken without an adoption path fix or manual migration.
  • The one-line change is correct and doesn't introduce regressions. However, the adoption path gap means the fix is incomplete for any deployment that already has SCIM-provisioned users. Those users still can't log in via OIDC after a re-sync, which is the stated goal of the PR. The issue is real and verified: the adoption condition (line 110) allows users with pre-existing scimExternalId through regardless of authMethod, and auth.ts explicitly blocks OIDC login for LOCAL accounts (lines 229–241).
  • src/server/services/scim.ts — specifically the adoption update block (lines 120–126) which should also set authMethod: "OIDC"

Comments Outside Diff (1)

  1. src/server/services/scim.ts, line 120-126 (link)

    Adoption path doesn't repair authMethod for existing SCIM users

    The fix correctly sets authMethod: "OIDC" for newly created SCIM users, but the adoption path (reached when a user already exists in the DB) only updates scimExternalId. This means any user who was SCIM-provisioned before this fix (and therefore has authMethod: "LOCAL" from the old schema default) will still be blocked from OIDC login even after the IdP sends a subsequent SCIM create/re-sync.

    The adoption condition at line 110 allows users with a pre-existing scimExternalId (regardless of authMethod) through to this update block, so the scenario is reachable in production for any tenant that already had SCIM provisioning enabled.

    Without this, the complete fix for existing environments requires either a data migration or manually deleting and re-syncing every affected user — an error-prone manual step that should be avoided when the adoption path already has the right context to perform the repair automatically.

Last reviewed commit: 072964e

@TerrifiedBug TerrifiedBug merged commit f122534 into main Mar 7, 2026
12 checks passed
@TerrifiedBug TerrifiedBug deleted the fix/scim-user-auth-method branch March 7, 2026 20:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant